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Truth arises more readily from error 
than from confusion. 

Francis Bacon 
Novum Organum 



The Penelope project: 


• Interactive, incremental, tool for formal 
verification of Ada programs (Larch/Ada 
specifications). 

— Structure or ordinary text editor 

— Permits development of program and 
proof in concert, "reuse by replay" 

• Covers large subset of sequential Ada. 


• Mathematically based. 
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Problem: specify "logic" of experimental Au- 
tomatic Guidance Control System for a 737 


• Pilot requests kind and degrees of auto- 
matic assistance 


• Requests may be honored, disallowed, "put 
on hold 


• Responses must be displayed 
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Work-in-progress: Larch/Ada specification 

• Formal specification of Ada code 

• Goals: precise; intelligible to designers and 
implementors 

• Currently wrong, but clear 
Related work 

• Original code (CSC) 


Experiment in redesign (NASA) 


















Some failures of informal description 

1. Ambiguous: “Select" a switch vs. “select" 
a mode. 

2. Incomplete: “CAS ENG may be engaged 
independent of all other AGCS modes except 
TIME PATH." 

3. Contradictory: 


• FPA ... cannot be deselected directly. 


• [if] ... appropriate selection of the FPA 
SEL . . . switch returns the mode to the 
off state . . . 
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Larch/ Ada specifications: "two-tiered" 

• Mathematical part (Larch Shared Language) 
defines vocabulary 

• Interface part (Larch/Ada): uses vocabu- 
lary to specify code 


Example: specifying executable addition 

Mathematical part: defines mathematical + 
on Int, the (infinite) domain of mathematical 
integers 

Interface part: Specifying evaluation of x+y 

• Type integer is “based on M Int. 

• Return value (x + y) if 

min < (x + y) < max. 

No side effects. 


• Otherwise, raise numeric_error. No side 
effects. 
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The mathematical part 


States: AGCS_state, Sensor_state, etc. 
Actions: 

{alt_eng_switch,. . . ,alt_eng_knob(i) 

alt_capture,. . . } 

Modes: 

{alt_eng,fpa-sel, vert_path,. . . } 
Transition operation: 

AGCS_state, Action, AGCS_state 

Observers: active2d, display, ... 
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Building mathematical part (the AGCS states) 

AgcsStructure : trait 
AGCS_state record of 
(on: Bool, 

modes: Set_of_modes, 
engaged: Engagement-status, 
setting: Value_settings, 
window: Window_array) 
includes Set(Mode,Set_of_modes) 

introduces 

transition: 

AGCS_state, Action, Sensor_state, 
Flight-plan — ► AGCS_state 
initial_on_state: — ► AGCS_state 

asserts 
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Description of mode changes caused by switches 


• Is the mode directly deselectable? 

• What mode changes result? 

• Under what conditions is the mode di- 
rectly selectable? 

• What mode changes result? 
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Building mathematical part (mode changes) 

HorPathSwitch : trait 

includes SwitchShell{hor_path} 
asserts for all 

[agcsmodes: Set_of_modes, 
pi: Flight_plan f 
sens: Sensor_state] 

hor_path_deselectable 
hor_path_selectable(agcsmodes,pl) = 

(auto e agcsmodes) a active2d(pl) 
hor_path_selection_result(agcsmodes f sens ( pl) 
[hor_path] u [cas]] 

hor_path_deselection_result(agcsmodes) = 
[tka_sel] u [[cas]] 
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Intuitive description of window status ( chosen 
vs. current ): 

• The u>_knob makes the corresponding w- 
window chosen. 

• Any action selecting the w mode makes 
the ^-window chosen. 


• Any action deselecting the w mode makes 
the w-window current. 


• Any other action leaves the status of the 
^-window unchanged. 
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Building the mathematical part (window changes) 


StatusShell : trait 

imports AgcsStructure 
introduces 

#. component : 

Window_array — » Window_status 
md: — > Mode 
knob : Value — ► Action 
asserts for all [agcs:AGCS_state, . . .] 

abbreviation 

ages’ == transition(agcs,act,sensor,plan) 
ages'. window. component = 

if md e agcs’.modes - aegs. modes 
then chosen 

elsif md e ages. mode - ages'. modes 
then current 

elsif act = knob(i) then chosen 
else ages. window. component 


Example: Stat usShell {alt ,alt_eng, Airspeed} 


Design of the code: 


• Packages panel-logic, display-manager, 
sensor_data F flight-plan, flight .control. 


• State of panel-logic based on AGCS_state, 
etc. 

• Actions procedures of panel-logic: 

— read State Of panel-logic, sensor-data, 
flight .plan 

— modify states of panel-logic, 
di splay .manager, flight-control 


• Consistent with polling, interrupts, etc. 
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Specifying the code: 


__| WITH TRAIT AgcsLogic, AgcsProperties , 

I LogicalDisplay 

| yxTH sensor .data, flight .plan, 

—| display .manager , flight.control 

, -t-ime-?- use sensor _data_types , 

with sensor _data_types, use 

package panel.logic 

— | BASED ON AGCS.state 
— | INVARIANT 

—| panel.logic . on -> good(panel_logic) 

—| INITIALLY not panel.logic . on 


end pane] — logic; 
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procedure att.cws.switch; 

— I WHERE 

— | GLOBALS IN panel.logic 

— I GLOBALS OUT di splay .manager, 

— | flight .control , 

— | panel.logic 


IN panel. logic .on 




OUT panel. logic = 
transition(IN panel.logic, 

att.cws.switch, * , *) 
OUT FORALL ss: Sensor.state : : 
look (display .manager ,ss) = 
display (panel.logic , ss) 

OUT FORALL md:mode : : 
f c .engaged (md , f 1 ight .control ) 
engaged (md , panel.logic) 

END WHERE; 



procedure turn_on_agcs 

— I WHERE 

« • • 

— | OUT panel_logic = initial_on_state 
• • • 

— I END WHERE; 


